Thanks @ben-dz — all five addressed in the latest push.

Major 1 — silent disconnect failure orphans host-netns state. Reworked to tear the old instance down with docker stop instead of docker exec … disconnect. That drives the container entrypoint's existing SIGTERM trap (docker-entrypoint.sh), which runs its own bounded doublezero disconnect (only when a tunnel is up) before doublezerod is killed — so removal no longer SIGKILLs a still-connected daemon. And it warns loudly on failure: since the container is --network host, a failed disconnect leaves doublezero1 in the host netns, so after removal the installer checks for that interface and warns that the on-chain session/routes may be orphaned. A stop that times out/errors before the forced rm also warns.

Major 2 — unbounded exec can hang forever. docker stop is bounded by the container's --stop-timeout (60s) and additionally wrapped in timeout 90, so a wedged doublezerod or a container in a restart loop can't hang the installer.

Minor 1 — headless regression + collapsed message. A no-TTY run with DZ_ASSUME_YES unset now reinstalls (with an explicit notice) instead of aborting, matching the pre-guard silent-reinstall behaviour so automation isn't broken. A genuine interactive decline still aborts, with its own distinct message. While wiring this I found [ -r "$TTY" ] is unreliable — a readable /dev/tty inode still fails to open with no controlling terminal (cron/systemd) — so detection now probes an actual /dev/tty open, which also sidesteps confirm()'s tty read in that case.

Minor 2 — network-unaware prompt. The warning now names the existing instance's env/image (via docker inspect), so the operator sees which network's container they're about to destroy.

Minor 3 — no bats coverage. Added tests/scripts/reinstall_existing.bats with a smarter docker stub that distinguishes ps -a -q (exists) from ps -q (running) and flips to "up" after docker run: running → docker stop before docker rm before docker run; stopped → no stop; no instance → no-op; headless → reinstall (not abort). All green alongside the existing preflight suite.

in the new 3b block, existing_env="$(docker inspect … 2>/dev/null | sed …)" is missing the || true that its sibling existing_img line has. Under set -euo pipefail, a failing command substitution in a plain assignment kills the shell — so a docker inspect failure (container removed between the docker ps -a detection and the inspect, or a daemon blip) silently aborts the whole installer before the "already exists" warning even prints.

Good catch @ben-dz — fixed in 0547a4c.

Added the missing || true to the existing_env line so it matches its existing_img sibling and stays best-effort:

existing_env="$($SUDO docker inspect -f '{{range .Config.Env}}{{println .}}{{end}}' "$DZ_NAME" 2>/dev/null | sed -n 's/^DZ_ENV=//p' | head -1 || true)"

Two failure shapes are now covered: a docker inspect that returns non-zero (container removed between the ps -a detection and the inspect, or a daemon blip), and — since it's a pipeline — head -1 closing the pipe early on multi-line env, which SIGPIPEs the upstream and trips pipefail even on success. Either way the label just goes empty; the "already exists" warning and the reinstall still proceed.

I also hardened the stub so this is actually regression-tested (it previously returned nothing for inspect, so it couldn't have caught this): docker inspect now emits realistic multi-line env + an image, and honours STUB_INSPECT_FAIL. New test — "docker inspect failing mid-teardown does not abort the installer" — asserts the installer still detects, warns, and reaches docker run; the running-instance test now also asserts the warning names the victim's env/image. All 7 green.

Note: on modern bash (5.x here) a bare x="$(false)" assignment doesn't actually trip errexit, but older bash (4.x on CentOS 7 / older Ubuntu servers — squarely in the curl|bash target set) does, and the head/SIGPIPE race bites everywhere — so the fix is warranted regardless.